Online transactions are becoming more prevalent. Similarly, online processing of transaction data is very common. One area with large amounts of transaction data is credit cards and debit cards. Data from all such credit cards transactions is handled electronically, which allows faster transmission of such data, but also comes with its own set of problems.
One area of credit card use is the issuing of cards and accounts to employees or agents of a company. The employee can then use the corporate card to charge all types of expenses related to their job with the company. These payments are often collectively referred to as “travel and entertainment” (T&E) expenditure and typically include hotels, meals, taxis, airline tickets etc. For example an employee who travels frequently on business would have a credit card to charge all the employee's travel related expenses. The employee then does not need to submit expense reimbursement reports for all their travel expenses, but have the credit card statement processed directly by the company. Employees may have several different corporate cards, each for a different purpose.
This great expansion of company-issued credit cards has caused a consequential increase in the company's accounting issues in handling these transactions. Statements from the credit card issuers must be processed by an accounting department, and expenses properly charged to the proper department or account within the company. The amount of transaction data, the complexity of the data, and the complexity of the company pay structure all create problems.
One problem is that although statements and transaction data from the credit card issuers is available in electronic format for easy access, each credit card issuer supplies such transaction data in a different format. There is no set industry standard for formatting of transaction data. Therefore the preliminary processing of transaction data requires different processing based on the format of the data. This limits a company's ability to automatically process the data, and may limit the company's choice of credit card issuers or the providers of the transaction data. The other choice is for a company to enter certain transaction data by hand, or spend time and money to develop preliminary processing applications to handle the different formats of received transaction data. Further, as new formats for transaction data are introduced, or older formats are updated, the data preliminary processing application must be updated.
A similar problem exists on the opposite side: transaction data that is to be exported from the database will be used by a variety of other applications. An example is general ledger systems used by businesses. There are a great number of different ledger products on the market, and as is typical, they each expect entries in a different format. Some example of ledger products are SAP, J D Edwards, Walker, Lawson, Coda, and Oracle Financials, etc. These examples are widely available standard ledger products. There are also many large businesses with their own custom built or modified ledger systems, with their own peculiar format requirements.
All these different ledger formats limit a system's ability to automatically export data to a ledger, and may limit the company's choice of what ledger systems can be used. Many businesses simply enter the data into the ledger by hand. The other choice is for a company to spend time and money to develop proprietary export functionality to handle the different formats for one or more ledgers. This also ties a company down to a certain ledger system because of the increased time and expense for change to a new system.
Ledger input is also very demanding. Many of the ledger systems require data in rigid spacing formats with fixed field lengths. They can not handle other formats, such as variable length fields, comma delimited fields, or other simplified data acquisition formats. This problem also limits the ability for a business to use a ledger format different from the one it already uses.